The Java™ technology is both a programming language and a platform, initially developed by Sun Microsystems, Inc. On one hand, the Java™ programming language is a high-level, object-oriented language and to a certain extent, similar to the C++ programming language. Java™ source code is written in plain text based on specific syntax and stored in files ending with the “.java” extension. The source code is then complied by the Java™ complier, javac, into a type of machine language called “bytecode” and stored in files ending with the “.class” extension. However, bytecode is not code that is native to a particular type of processor. Instead, to execute a complied Java™ program, the bytecode is interpreted by the Java™ interpreter, java, within the Java™ runtime environment, known as the “Java™ Virtual Machine” (JVM).
On the other hand, the Java™ platform is the software environment in which a Java™ program runs. It contains two components: the JVM and the “Java™ Application Programming Interface” (JAPI). The JAPI is a large collection of ready-made software components that provides many useful functions or capabilities. It is grouped into libraries of related classes and interfaces, known as “packages.” Some of the common JAPI include Java™ Enterprise Edition (EE), Java™ Standard Edition (SE), and Java™ Micro Edition (ME).
Java™ EE is package containing a set of coordinated technologies and practices that enable solutions for developing, deploying, and managing multi-tier, server-centric applications. Some of the Java™ EE technologies are: web services technologies, component model technologies, management technologies, transaction technologies, etc. Specifically, Java™ EE contains web application servers that provide containers to deploy enterprise applications including web services. Java™ SE provides a complete environment for application development on desktops and servers and for deployment in embedded environments. It provides the basis for security, database connectivity, etc.
The core Java™ platforms also contain an “extension mechanism” that enables the JVM to use Java™ classes contained in optional packages (formerly known as “standard extensions”) that are not part of the core platforms in much the same way as the JVM uses the classes contained in the core platforms. Thus, software developers may extend the functionality of the core platforms by developing their own Java™ packages and attaching these optional packages to the core platforms.
Many such optional packages exist—one of which is the “Java™ Business Integration” (JBI) package. JBI extends Java™ EE and Java™ SE and enables the creation of a Java™ business integration environment for specifications, such as Web Service Choreography Interface (WSCI), Business Process Execution Language for Web Services (BPEL4WS), and the World Wide Web Consortium (W3C) Choreography Working Group. As part of JBI, a new layer of standard metadata in the web services stack is being formed to help define standards for business integration. For example, the term “business protocol” is the metadata used to describe the interaction between a set of business processes that implement the roles of partners within a larger service composition. The term “abstract business process” is the metadata that describes how a business process, within a business protocol, choreographs its role in a service composition so that its partner processes understand how to interact with it. JBI employs this concept and defines its own set of abstract business process metadata using open-ended components. Thus, fundamentally, JBI includes a container and various plug-in components, whereas the container hosts the plug-in components and the plug-in components communicate via message routers.
JBI has a service-oriented architecture and treats its components as service providers and consumers. JBI divides the task of supporting these components into three roles: the JBI Environment, the JBI Machine, and the JBI Binding. The Environment defines a standard internal representation for business protocol messages based on standard business protocol metadata. Each JBI Machine is responsible for supporting the lifecycle of a particular class of JBI Components. Each JBI Binding is used by the Environment to communicate with external services via specific business protocol bindings. Thus, many disparate protocols, bindings, and message formats exist, which are capable of being exchanged. No standard communication mechanism exists between JBI service providers/consumers and the Java™ EE technologies, so implementers currently manage these differences individually on a case-by-case basis.